Fleet changelogs · dev.ecs0.net
jdmbair13m5 - changelog - roodb-fleet-install-and-host-path-audit - claude - doctor-audit-install - fleet - 20260823-2119

jdmbair13m5 - changelog - roodb-fleet-install-and-host-path-audit - claude - doctor-audit-install - fleet - 20260823-2119

Completed: 2026-08-23 21:19:04 EDT Started: 2026-08-23 00:04:37 EDT (session spanned ~21h; user away for ~20.5h of it) Host: jdmbair13m5 · Agent: claude (session richh-b6) · Scope: all six fleet hosts

Summary

Ran /doctor on jdmbair13m5, audited richh's home for stale rename paths from a non-richh account, built rooDB universal from HEAD and installed it on all six Macs, and confirmed there is no halted agy work. One shared-file edit to FLEET.md, declared by check-in first.

1. /doctor — jdmbair13m5 (no defects)

2. Stale-path audit of richh's home (READ-ONLY, then peer-fixed)

Run exactly as requested: from rdmsm4x, in as joey@jdmbair13m5, via sudo, never as richh. Inner hop pinned by host key SHA256:OXqHs7H9D9EPqHjZSjAiTimSYJ/k+NTx9fuVPMOYKoM, confirmed to be this machine (mac-fleet-host-onboarding non-negotiable #1). Script: /Users/Shared/audit_richh_paths.zsh (read-only, never writes).

Clean: account record (RecordName richh, NFSHomeDirectory /Users/richh, UID 502, Secure Token ENABLED), no stale rich shortname in any group, /Library/LaunchAgents, /Library/LaunchDaemons and /etc all zero hits, zero ownership anomalies.

Fixed by peer session richh-75 at 00:28-00:32 EDT (surfaced by this audit, not fixed by me; snapshots at ~/.local/state/permissions-repair-20260823-003209/):

Left alone deliberately: six com.apple.* binary plists under ~/Library/Preferences (dock, finder, cloudphotod, CallHistorySyncHelper, FamilyCircle, mediaanalysisd) still carry /Users/rich. Report-only per Phase 2; macOS rewrites them on next preference write. Also com.google.GoogleUpdater.wake.plist — vendor plist, rewrites itself.

3. FLEET.md — one declared edit

Check-in published FIRST: ~/.agent-coordination/checkins/claude-jdmbair13m5-20260823-211750.md Backup: ~/.agent-coordination/FLEET.md.bak.<ts> · File now 498 lines, note at line 44.

Added: /Users/rich -> /Users/richh is LOAD-BEARING on jdmbair13m5. Dock stores its Downloads stack as /Users/rich/Downloads/; Finder holds /Users/rich/Desktop/Desktop%20(icloud)/. Both resolve through the symlink. Deleting it breaks them silently, with no error. This upgrades the link from "rename compat nicety" to "do not remove" and was previously recorded nowhere.

4. rooDB — built universal and installed on ALL SIX hosts

Source: rdmsm4x:~/dev/apps/roodb-app HEAD 33fb8b3 2026-08-23 19:02:22 -0400, tree clean. (~/dev/apps/rooDB is a tombstone containing only README-MOVED.md — not the live tree.) Installer: rdmsm4x:~/.local/state/roodb_fleet_install.zsh v1.0.0, dry-run by default, --apply required. Stage: rdmsm4x:~/.local/state/roodb-stage-20260823-211321. Installs to /Applications/rooDB.app and ~/.local/bin/{roodb-cli,roodb-mcp}.

Three traps a naive "copy dist/ everywhere" would have hit:

  1. Committed dist/ binaries are arm64 thin. Deployed fleet-wide they would silently fail to launch on rdmpw3265m and rdmpw3275m (Intel). Fix: build with --arch arm64 --arch x86_64 (~20s).
  2. swift build warns "x86_64 architecture is deprecated for your deployment target (macOS 27.0)". That concerns the BUILD SETTING, not the deployment floor. The produced binary is minos 14.0 on both slices and runs on 26.6.2 / 26.7 / 27.0. Do not read that warning as "Intel unsupported".
  3. Bundle is ad-hoc signed (no Team ID), so inter-Mac copy sets com.apple.quarantine. The installer clears it per host.

Verified per host — archs / signature / CLI, all six identical: rdmsm4x · jdmbair13m5 · rdmbair13m5 · rdmbair15m5 · rdmpw3265m · rdmpw3275m => archs=[x86_64 arm64], sig=valid, rooDB CLI v2026.1. Independently re-verified from jdmbair13m5 (not the builder) against /Applications/rooDB.app.

Reachability finding: rdmbair15m5.local does NOT resolve from jdmbair13m5. The install still reached it because distribution runs FROM rdmsm4x. Use rdmsm4x as the hub for fleet-wide operations initiated on jdmbair13m5.

5. agy — nothing to resume (verified, not assumed)

6. Statusline — already correct, no change

~/.claude/statusline.sh is byte-identical to rdmsm4x (86252490851c98a46cf32951a73586ad59b75b3bd68f771a3022344141d46bde), and the statusLine settings key already matches. v2.2.0 is the full-coverage build (CTX + 5H + 7D meters; host/date/time/dir/git/repo/worktree/PR; model/effort/thinking/fast/style/agent/cost). Test-run: exit 0, renders correctly. Nothing to do.

Permissions — disclosure

At 00:15 EDT, BEFORE the current CLAUDE.md prohibition existed on this host, Rich explicitly selected bypassPermissions from a multiple-choice question and I wrote the key. Current value IS bypassPermissions, matching his standing instruction, so nothing needs correcting. The new rule has been read and the key will not be touched again. Backup of that edit: ~/.claude/settings.json.bak-20260823-0013. Correction: bak-20260823-112919-pre-bypass-restore does NOT exist on jdmbair13m5.

OPEN — upstream defect, owner action required

The /doctor skill's check 8 hardcodes permissions.defaultMode = "auto" as its "(recommended)" option. This collides head-on with Rich's standing instruction that the key is bypassPermissions and that no agent may change it. The skill cannot see the standing instruction, so this recurs on every /doctor run on every host until the skill is amended. It is the most likely route by which auto reached rdmsm4x and rdmbair15m5. Not amended here — a shared skill should not be edited unilaterally; route to whoever owns skill propagation.

Undo